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(57) Abstract: A computer network (100) having a requesting node (1 10) and a providing node (108) permits data transfer there- 
between when permitted by an authorizing node (112). Reports generated in response to authorizations and reports generated in 
response to data transfers are reconciled at a reconciliation node (1 18) to improve the accuracy of payments collected and paid for 
use of the data. Such payments include copyright royalties for audio, video, and other works recorded in digital format. 
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SYSTEM AND METHODS PROVIDING SECURE DELIVERY 
OF LICENSES AND CONTENT 

CROSS-REFERENCE TO RELATED APPLICATIONS 
5 This application is a continuation in part application of and claims priority to 

application Serial No. 09/717,614 filed November 21, 2000 by Nuttall, which is a divisional 
application Serial No. 09/055,068 filed April 3, 1998 by Nuttall, now U.S. Patent 6,202,056. 

10 FIELD OF THE INVENTION 

The present invention relates to computer networks for data transfer and to monitoring 
use of such data for example for fee accounting for usage rights. 

BACKGROUND OF THE INVENTION 

15 Publishers of information in digital form desire to prevent the unauthorized and 

unaccounted distribution or usage of electronically published materials. Electronically 
published materials are typically distributed in a digital form and recreated on a computer 
based system. Audio and video recordings, computer programs, books, and multimedia are 
examples of works that are suitable for publishing electronically. The sales revenue for 

20 companies in the electronic publishing and information systems industries includes payments 
based on an accounting for delivery of information in digital form, for example the sale of an 
audio CD at a retail outlet. Any unaccounted distribution of a work results in decreased 
revenue to the distributor and decreased royalty for the owner of usage rights in the work. For 
example, being able to copy an audio recording CD to another digital medium from which the 

25 audio can be retrieved and played circumvents payment for distribution from which royalty for 
copyright may have been due to the owner of rights in the work. 

Owners of rights in electronically published works also desire to prevent the 
unauthorized and unaccounted distribution or usage of such materials. When records of the 
distribution and usage of a work are held exclusively by the distributor, falsification of records 

30 results in increased profit for the distributor and loss of royalty income for the owner of rights. 

Unauthorized and unaccounted distribution can be curbed by preventing unauthorized 
copying of the work onto digital storage media and unauthorized transmission of the work over 
computer networks. Unauthorized and unaccounted usage can be curbed by preventing storage 
of the work for reuse or by monitoring the use of stored copies. 
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Existing systems and methods for preventing storage, transmission, and unmonitored 
use of digital works place a heavy hurden of cost on the consumer desiring access to a work in 
digital form. The continued expansion of publication and use of works in digital form cannot 
remain within the policies for intellectual property protection (such as providing incentives to 
5 authors and publishers) without systems and methods for computer network operation that 
provide an accurate basis for usage fees. 

SUMMARY OF THE INVENTION 
A system for the control of distribution and use of digital works includes a distribution 

10 and usage reporting mechanism for accurately calculating fees associated with such 

distribution and use. The system operates according to a method for transferring data from a 
content providing node to a content requesting node. The method includes the steps of: (a) 
transmitting a first request to the content providing node, the first request for notifying an 
authorizing node; (b) receiving a permit from the authorizing node in response to the 

1 5 notification; (c) determining a file name in response to the permit; (d) transmitting to the 

content providing node a second request comprising the file name; (e) transmitting to an event 
reporting node a first report in response to receiving the permit; (f) receiving data from the file; 
and (g) transmitting to the event reporting node a second report in response to receiving the file. 
By obtaining the permit without direct communication between the content requesting 

20 node and the authorizing node, manipulation of the authorizing node by the content requesting 
node is prevented. The content requesting node has an incentive to manipulate the authorizing 
node in order to receive unlimited authorization. The content providing node has an incentive 
to maintain proper authorization because revenues to the content providing node may be based 
on the number of authorized transfers. 

25 Although a work may be identified in the request received at the content providing node, 

the content providing node may be prevented from obtaining information leading to the 
filenames that comprise the work. The content providing node may have an incentive to 
provide free transfers of the work for other commercial or personal use; however, by 
determining the file name in response to the permit and preventing access to the permit from 

30 the content providing node, the content providing node cannot identify particular files that 
correspond to a particular work. 

By transmitting reports from the content requesting node to an event reporting node, 
modification of data transfer reports by the content providing node is prevented. Accurate 
records provide basis, for example, for fees payable to owners of rights in the work. 



2 



WO 03/034286 



PCT/US02/33564 



By transmitting a first report prior to data transfer and a second report after data transfer, 
a duration of the usage of the data may be used as a basis, for example, for revenues to 
distributors and payments to owners of rights. Falsification of the duration of usage by the 
content requesting node is prevented. 

5 

BRIEF DESCRIPTION OF THE DRAWING 
Embodiments of the present invention will now be further described with reference to 
the drawing, wherein like designations denote like elements, and: 

FIG. 1 is a block diagram of a network in one embodiment of the present invention; 
10 FIG. 2 is a data flow diagram for a portion of the network of FIG. 1 that, inter alia, 

creates content files on a content providing node; 

FIG. 3 is a data flow diagram for a portion of the network of FIG. 1 that, inter alia, 
satisfies a data transfer request; 

FIG. 4 is a data flow diagram for a portion of the network of FIG. 1 that, inter alia, 
15 accomplishes payments, for example, to owners of rights in data transferred; 
FIG. 5 is a table of outcomes for lost transmissions of reports; 
FIG. 6 is a functional flow diagram for a portion of a method of validating a request by 
an authorizing node; 

FIG. 7 is a functional flow diagram for a portion of a method of creating a permit by an 
20 authorizing node; 

FIG. 8 is a functional flow diagram for a portion of a method of validating a permit by a 
content requesting node; 

FIG. 9 is a functional flow diagram for a portion of a method of reporting, by a content 
requesting node, a start of data transfer; 
25 FIGs. 10 through 12 are functional flow diagrams for portions of a method of obtaining 

and using content files and reporting a summary of data transfer; 

FIG. 13 is a memory map of a data structure of a map file of the present invention; 

FIG. 14 is a memory map of a data structure of a header of a content file of the present 
invention; 

30 FIG. 1 5 is a memory map of a data structure of a request of the present invention; 

FIG. 16 is a memory map of a data structure of a permit of the present invention; 
FIG. 1 7 is a memory map of a data structure of a start report of the present invention; 
FIG. 18 is a memory map of a data structure of a summary report of the present 
invention; 
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FIG. 1 9 is a memory map of a data structure of an access report of the present invention; 
FIG. 20 is a memory map of a data structure of a debit report of the present invention; 
FIG. 21 is a functional block diagram of a system according to various aspects of the 
present invention; 

5 FIG. 22 is a functional flow diagram for a portion of a method of selling a permit; 

FIG. 23 is a functional flow diagram for a portion of a method of delivering a product; 
FIG. 24 is a functional flow diagram for a portion of a method of detecting a breach of 
security; 

FIG. 25 is a functional block diagram including data flows describing an architecture 
10 according to various aspects of the present invention; and 

FIGs. 26A-26I present memory maps of data structures used in the architecture of FIG. 

25. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

15 Data transfer in the present invention is illustrated among computer systems using a 

communication network. A communication network of the present invention includes at least 
one computer system at each of several network nodes. Each node is coupled by a link from 
time to time for communication with other nodes of the network. Each link includes 
conventional computer communication technology of the type including, for example, local 

20 area, wide area, dedicated telephone, or satellite services and including conventional data 

communication hardware and software. The popular computer networks known as the Internet, 
World Wide Web, and National Information Infrastructure are examples of such a 
communication network having nodes possibly at physically separate locations and addressed 
by a node address, for example a uniform resource locator (URL), a name from a domain name 

25 system (DNS), or an Internet Protocol address (IP). 

Communication network 100 of FIG. 1 includes computer systems, each shown in a 
block, that communicate for data transfer. Communication of messages is illustrated by one or 
more lines between blocks, though it is apparent that one communication link between any two 
blocks is sufficient for any number of message lines. Practice of variations of the invention is 

30 independent of whether such a link is maintained continuously, as in a dedicated line, or is 
maintained for the duration of the message as in some public multiple access facilities. 

Communication technology provides known mechanisms and computer software for 
message transfer. This technology surrounds the message content data with other data that 
provide a mechanism for various purposes including tracking messages, synchronizing 
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equipment, and assuring accurate and secure transfer of message content data. In the 
description that follows, digital works are transferred between nodes. The term "content," 
therefore, refers to a digital work or a portion thereof. 

Network 100 includes content acquisition node 102, content managing node 104, 
5 provider preparation node 1 06, content providing node 1 08, content requesting node 1 1 0, 
authorizing node 1 12, banking node 1 14, event reporting node 1 16, and reconciling node 1 18. 

In operation, for content to be transferred on request to any of perhaps millions of 
content requesting nodes, the content is first received from a source and formatted for storage 
on one or more of perhaps thousands of content providing nodes. Initially, a content developer, 

10 publisher, or distributor provides digital works, for example multimedia files, to content 
acquisition node 102 for encoding in a format efficient for storage and access by content 
managing node 104. Content is conveyed on line 130 as it becomes available for management 
by content managing node 104. Content from content managing node 104 is conveyed on line 
132 and then made unique to each content providing node 108 by formatting processes 

15 performed by provider preparation node 106. Content providing node 108 receives content 
from time to time from provider preparation node 106 on line 134. 

To request a data transfer in a preferred embodiment for the Internet, a user or 
consumer at content requesting node 110 uses a network browser, such as Microsoft Internet 
Explorer, and follows an Internet link (clicks on a portion of an HTML file display), causing a 

20 message in HTTP format to be conveyed on line 136 to content providing node 108. Content 
providing node 108 forwards the request on line 138 to authorizing node 112. If the request is 
valid, authorizing node 1 12 creates a permit and sends it on line 146 to content requesting node 
1 1 0. A permit is a message created to uniquely respond to the request from a particular content 
requesting node. Using portions of the permit, content requesting node 110 requests on line 

25 136 particular files from content providing node 108. In response, such particular files are 
conveyed on line 148 to content requesting node 110, completing the data transfer. 

Accounting for the above described transfer of content includes, for example, receiving 
payment from the user of content requesting node 110, making payment for distribution 
services to at least the operator of content providing node 108, and making payment to one or 

30 more owners of rights in the content. These accounting transactions find accurate basis in a 
reconciliation of reports from a variety of network nodes that are reported at separate times 
during the data transfer process. For example, when authorizing node 1 12 receives the request 
and queries an access authority data base on content managing node 104 via lines 140 and 142, 
content managing node 104 logs the query and reports the log on line 156 from time to time to 
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reconciling node 118. With knowledge of the identity of content requesting node 1 10, an 
identity of the user, and a price of the requested work for a requested purpose (for example, 
copy or preview), authorizing node confirms a debit of an account kept on banking node 1 14 by 
messages conveyed on line 144. Banking node 1 14 logs the debit and reports the log on line 
5 154 from time to time to reconciling node 118. When the data transfer begins and again when 
at least some of the data has been transferred, content requesting node 1 10 reports on line 150 
to event reporting node 116. Event reporting node 1 16 logs the events and from time to time 
reports the log on line 152 to reconciling node 118. By comparing reports received on lines 
152, 154, 156, and possibly 158 (from content providing node 108), reconciling node 118 

10 distinguishes valid complete data transfers from incomplete transfers and from events that 
could indicate intentional interference with the integrity of network 100. For each valid 
complete transfer, reconciling node 118 allocates revenues generated from the debits of users' 
accounts, discussed above with reference to line 144. Reconciling node 118 then initiates 
funds transfers with messages to banking node 1 14 on line 160 for payments of, for example, 

1 5 distribution fees and royalties. 

Each node of network 100 may represent more than one conventional computer system 
that performs, inter alia, methods of the present invention. Multiple computers or multiple 
data storage devices may be necessary for maintaining a particular node's functions operational 
in periods of high network traffic. Such multiple computers may be at various physical 

20 locations, provided that only one network node address (for example, an IP address) is 
associated with each node. 

A method of the present invention for preparing content for storage on a content 
providing node includes separation of content and map information. When content is divided 
for convenience into several files in a conventional file storage system, map information 

25 identifies the particular files from the entire inventory on the storage system and the order of 
presentation of the files for reconstituting a particular work. Separation of content and map 
information facilitates security measures without unduly compromising rapid provision of a 
work or performance of a work on a content requesting node. 

For example, as shown in FIG. 2, content acquisition node 102 encodes (using 

30 conventional data formatting and compression technology) contract items associated with the 
work and encodes the work itself. When the work is primarily an audio recording, contract 
items may additionally include: name of the album, producer, label, publisher, mail order 
company, publishing year, bar code, album and track distribution levels, title of a track, 
performers, authors, composers, ISRC code for the title, language, track number, duration, 
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extract start and end times, number of allowed copies, price to preview (listen), price to make 
copy, rights collecting societies, authorized distribution areas, album cover picture, liner notes, 
other graphics, music style, associated country, and possibly pictures associated with the 
recording and text to be shown while the work is being played. Receiver processes 204 and 
5 206 (using conventional communication and data storage technology) on content managing 
node 104, receive the encoded contract items and content and store each respectively on access 
authority data base (AADB) 208 and content masters store 210. 

When a particular content providing node 108 is identified, works to be provided by 
that node are selected from content masters store 210 and scrambled by process 214 (using 

10 conventional data security technology). Scrambling is a preferred (though weak) form of 

encryption that allows some security without unduly burdening data transfer or use of the work 
when requested. The scrambled result of a work is combined with a header, which includes 
encrypted data from access authority data base 208, to form one or more content files. Content 
files 217 are transferred for storage on store 216 of content providing node 108. 

1 5 Process 212 prepares map files 2 1 8 for transfer and storage on store 216. Descriptors of 

the work, of the content files, and of content providing node 108 are obtained from AADB 208 
and formatted and encrypted by process 212 (using conventional data formatting and 
encryption technology). Some or all of the descriptors, alone or in combination, may be 
subject to rigorous encryption. The map file permits content file locations to be random or at 

20 least unpredictable in store 216, substantially decreasing the likelihood of unauthorized access 
without the system performance penalties associated with encrypting content files 218 on store 
216. 

In a preferred embodiment for an audio recording, the map file includes a version 
number of a group of content files and a node address and pathname to each content file of the 

25 group. The node address corresponds to the unique node address of the content providing node 
for which content files are being prepared. Each node address and pathname is encrypted 
separately. Each content file of the group provides a different level of sound quality for the 
same audio material. Different levels of quality provide, for example, flexibility in meeting the 
audio fidelity of different content requesting nodes. FIG. 13 illustrates an example map file 

30 data structure 1 300 when instantiated in memory at provider preparation node 106. FIG. 14 
illustrates an example data structure 1400 of a header of a content file when instantiated in 
memory at provider preparation node 106. 
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Content files 217 and map files 218 are organized for convenient access on store 216 
using a conventional file system such as a directory system, shadowed physical drives, or a 
RAID system. 

As indicated by ellipsis in FIG. 2, many content acquisition nodes may supply content 
5 to content managing node 104. Many content providing nodes may be supplied with content 
files from content managing node 104. Due to differing security and traffic support 
requirements, it is preferred to operate network 1 00 with physically separate nodes 1 04 and 1 06. 
In a variation, the functions of nodes 104 and 106 may be combined on one node or combined 
with content acquisition node 102. 

10 Various methods of the present invention for data transfer use to advantage (a) the 

cooperation of several network nodes, (b) linking a request through a registered node, (c) 
creating a permit using data from multiple sources, (d) using encryption, current time of day, or 
encryption keys based on unique properties of a node, and/or (e) providing unique structures 
and separate access to content files and map files. These features, inter alia, accomplish 

1 5 validating the request, validating the permit, and validating the data transfer operation itself. 
When validation is unsuccessful, data transfer is stopped, preserving the integrity of network 
100. The integrity of network 100 may be compromised by unauthorized copying, transfer, or 
use of a digital work. 

For example, as shown in FIG. 3, a data transfer begins at content requesting node 

20 (CRN) 110. There a consumer or service user obtains a listing of titles, each title for a digital 
work. Process 302 (using a conventional browser and operating system) responds to user input, 
for example a mouse switch closure ("click") when an on-screen cursor points to a portion of 
an HTML page identifying a title, and in the conventional manner generates a message 303 to 
content providing node (CPN) 108. Process 304 (using conventional HTTP message 

25 technology) forwards the request 305 to authorizing node (AN) 1 12. FIG. 15 illustrates an 
example request data structure 1500 when instantiated in memory at authorizing node 1 12. In 
a variation, process 304 determines the price to be billed for the request type and title and 
includes price and price currency with the forwarded request. Price information is stored in file 
306 which is available for editing by the operator of content providing node 1 08. In a 

30 preferred embodiment, validate payment process 310 obtains price information via the 

associated map file from each content file after the validity of the request has been determined. 

Process 308 validates the request by denying further processing to requests that do not 
meet predetermined criteria. In one variation, shown in FIG. 6, process 308 includes the steps 
beginning at step 600. At step 602, the node address of content providing node (CPN) 108 is 

8 
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obtained from access authority data base (AADB) 208. At step 604, the CPN node address as 
provided in request 305 is compared to the CPN node address as provided from AADB 208. If 
a match is found, control passes to step 606, else to step 608 where the request is ignored. At 
step 606, the node address of the calling page (which contains the link that was followed by 
5 process 302) is compared to the CPN node address provided by AADB 208. If a match is 
found, the request is considered valid and control passes to process 310, else to step 608 where 
the request is ignored. 

Process 310 (using conventional data base and communication technology) validates 
payment by the user by confirming that the user (via pay price process 3 1 0) has made a proper 

10 debit on the user's account. If a debit cannot be confirmed, request 305 is ignored. If 
confirmation of the debit transaction is successful, control passes to process 312. 

Process 312 creates a permit by combining information from more than one source. In 
one variation, shown in FIG. 7, process 312 includes the steps beginning at step 700. At step 
702, a map file 315 for the requested content is obtained either from the request or from store 

15 216 on content providing node 108. At step 704, content providing node address, content price, 
and price currency are obtained from request 305. At step 706, local date and time are obtained 
from the authorizing node 112. These data items are arranged, for example, in data structure 
1600 instantiated in memory of authorizing node 1 12, as illustrated in FIG, 16. At step 708 
some or all data in permit data structure 1 600 are encrypted to provide permit 313. At step 710, 

20 permit 313 is sent to content requesting node 1 10. 

Process 314 validates the permit by stopping the transaction for permits that do not 
meet predetermined criteria. In one variation, shown in FIG. 8, process 314 includes the steps 
beginning at step 800. At step 802, that portion of the permit that is encrypted is decrypted. At 
step 804, the syntax of each content file location (content.CPN.node address.pathname) is 

25 checked. The several pathnames in the permit provide ready access to the content file 

matching the sound quality level specified in request 305 (see FIG. 15, request. sound.quality). 
If the syntax check fails, control passes to step 810 to stop the transaction. Otherwise control 
passes to step 806 where the content requesting node address provided in permit 313 is 
compared to the node address of content requesting node 110. If no match, control is 

30 transferred to step 810. If a match is found, control passes to step 808, the current date and time 
on content requesting node 1 10 is compared to the date and time value stamped by authorizing 
node(AN) 112 on permit 313 (AN.date.time). If the current time is more than a predetermined 
amount (for example, 5 minutes) after AN.date.time, then control passes to step 810 and the 
transaction stops. Otherwise, control passes to step 812 and, in due course, to process 316. 
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Process 316 reports the start of a data transfer between content providing node 108 and 
content requesting node 110. Generation of the report may occur before data transfer actually 
starts or during an initial phase of data transfer. A start report is made to one or more event 
reporting nodes as specified by a list on content providing node 108. The report is transmitted 
5 by packet message techniques on a separate port so as to avoid interference with the data 
transfer itself which may be underway on another port. The two ports may share the same 
communication hardware such as a single line to an Internet Service Provider, as is well known 
in applications of TCP/IP. For other communication hardware and software configurations, 
concurrent ports may be arranged on two or more hardware communication links. 

10 In one variation, shown in FIG. 9, process 316 includes the steps beginning at step 900. 

At step 902, one or more event reporting node addresses and the content managing node 
address are obtained from list 3 1 8 on content providing node 108. At step 904, a port is opened 
for each event reporting node on list 318. In a preferred embodiment, ports 1000 through 1016 
are used, although other port numbers may be equivalently accommodated by the 

1 5 communication software on content requesting node 110. If no event reporting node 

successfully responds after attempts have been made to couple it for communication, then 
either the transaction is stopped or the transaction continues without the capability to generate 
reports. At step 906, a port is opened for reporting to content managing node 104, using the 
next available port number from the range 1000 through 1016. At step 908, information from 

20 request 305 is obtained and placed in a data structure in memory. FIG. 17 illustrates a start 
report data structure 1700 when instantiated in memory at content requesting node 110. For 
data structure 1700, such data includes the content requesting node address, the username and 
password, and the price, currency, and specified sound quality. At step 910, data from permit 
3 13 is added to the start report data structure. For data structure 1700, such data includes the 

25 content file location for the specified sound quality level, i.e. a corresponding 

content.CPN.node.address.pathname.quality.level. At step 912, data from the content file 
header is added to the start report data structure. For data structure 1700, such data include the 
title, artist, copyright, duration, ID.code.type (whether ISRC, ISWC, or etc.), the 
ID.code.number, the content providing node address, and a file number (a serialized number 

30 assigned by encoding process 202). At step 914, local values of the content requesting node are 
added to the start data structure. For data structure 1700, such values include a transaction 
number for discriminating reports from the same user, the current date and time, an encryption 
key unique to the content requesting node, and values from which the country in which content 
requesting node 1 10 is located. These later values include in one variation of the present 

10 
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invention, the time zone, the language identified by the operating system of node 1 10 and the 
keyboard identified by the operating system of node 110. Country location is important to 
allocating royalties under the laws that vary from one jurisdiction (country) to another. At step 
916, the report is placed in final format using conventional techniques and at step 918 it is sent 
5 to each event reporting node, for example node 116, and to content managing node 104. 

Process 320 obtains and uses the requested content files. After a content file header has 
been received by process 320, the transaction may be stopped if contents of the header do not 
compare favorably with the permit. In one variation, a summary report is prepared before data 
transfer of all requested files is complete. Further requests for files may be made in response to 

10 receiving an acknowledgement that the summary report has been received by the event 

reporting node. In a second variation, a duration of use of the files is measured and reported in 
a summary report, prepared and sent after all files have been received or usage is determined to 
be substantially completed. In the later case, shown in FIG. 10, process 320 includes the steps 
beginning at step 1000. Atstep 1002, a port is opened for content provider node file transfer (in 

15 addition to ports opened for reporting as discussed above). At step 1004, the header of the 
requested content file is obtained. The pathname to this content file is provided in permit 313 
for a corresponding sound quality of content requesting node 110. After decrypting the 
pathname itself, at step 1006, the header of the specified content file is decrypted. At step 1008, 
if the content providing node address in the obtained content file header does not match the 

20 content providing node address as permitted, the transaction stops at step 1010. Otherwise, 
control passes to step 1012. 

At step 1012, the usage mode as permitted is compared to the usage mode as requested. 
The user specifies a usage mode at the time of picking a title for a digital work to facilitate 
calculation of an appropriate price. For example, in many cases, the price for previewing a 

25 work (as in listening to a portion of an audio work) is less than the price for making a copy of a 
work for unlimited use. If the requested and permitted usage modes both indicate a copy is to 
be made, that is, the data transferred will be stored for repeated use, then control passes to step 
1202 on FIG. 12. Otherwise, control passes to step 1 102 of FIG. 11. Steps 1 102 through 1 108 
obtain all subsequent blocks of the requested content file and, after each block is received, 

30 perform the digital work according to the data in that respective block. Unscrambling of the 
data may be required. Performance or preview may be, for example one or more of the 
following: playing audio, showing visual, performing multimedia, or executing computer 
program digital works. For example, when an audio file is being received, unscrambling is 
performed and the resulting data may be played without interruption. 
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At step 1110, information from several sources is combined to form a summary report. 
One purpose of the summary report is to indicate for purposes of reconciliation, the duration 
the digital work was being performed. FIG. 1 8 illustrates a summary report data structure 1 800 
when instantiated in memory at content requesting none 110. For summary report 328, data 
5 items from start report structure 1700 (having the same names) are formatted in summary 
report data structure 1800. At step 1 1 12, the summary report is sent through ports opened in 
steps 902 and 904 to one or more event reporting nodes. The transaction is completed at step 
1114. 

If at step 1012, a copy of the work has been permitted, control passes to step 1202. At 

10 step 1202, a destination file for receiving the digital work is opened on the content requesting 
node 110. At step 1204, an encryption key is prepared using conventional data security 
technology. At step 1206, the content file header is obtained and written to the destination file. 
At steps 1208 through 1214, each block of the requested content file is obtained, encrypted, and 
written to the destination file. At step 1216, the destination file is closed. At step 1218 the 

1 5 transaction is completed. 

From time to time, reports are generated by various nodes for checking the integrity of 
network 100 and for allocating revenues received by debiting user accounts as described with 
reference to FIG. 3 process 310. Five reports are provided in network 100. Access report 332 
is provided by content managing node 104 from queries of AADB 208 initiated by authorizing 

20 node processes 308 through 312. FIG. 19 is a memory map of data structure 1900 of an access 
report record when instantiated in memory of content managing node 104 or reconciling node 
118. Report 342 is provided by banking node 1 14 from debit transactions requested by process 
310 of authorizing node 112, FIG. 20 is a memory map of a data structure of a debit report 
record when instantiated in memory of banking node 1 14 or reconciling node 118. Reports 326 

25 and 328 respectively provide the start and summary information from content requesting node 
1 10. Data structures 1700 and 1800 correspond to a single record of the start report and 
summary report respectively when instantiated in memory of reconciling node 118. Finally, 
report 336 describing what content files were sent and when sent may be generated by content 
providing node 108. 

30 Each report consists of multiple records, each record having multiple fields. Because 

these reports have some fields in common, comparison of the data in identical fields 
("reconciliation") provides the basis for distinguishing valid complete transactions from 
interrupted and unauthorized transactions. For example, an access report record 1900, debit 
report record 2000, start report 1 700, and summary report 1 800 each include a tracking field for 

12 
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the value: request.CRN.node.address.transaction.number. By noting whether all four records 
having the same value for this tracking field have been received at reconciling node 118, 
conclusions about network integrity and allocation of funds can be reliably made. 

A method for reconciling reports of the present invention includes accommodations for 
5 high volume event report processing. In addition, reconciled reports may be used to identify 
nodes having suspect operations and thereby provide a way of detecting unauthorized copying 
and use of digital works. 

In combination with the operation of the AADB 208, unauthorized use may be blocked. 
For example, if unauthorized transactions frequently involve the same content providing node 
1 0 address, that node address may be deleted from the list of registered content providing nodes by 
an appropriate operation on AADB 208. When a content requesting node makes a request 
through the link at the offending content providing node address, the request will be denied at 
the authorizing node. 

An example of a reconciliation method of the present invention is illustrated in FIG. 4. 

15 Event reporting node 116 receives start report 326 and summary report 328 at high traffic 
levels from numerous content requesting nodes. Each report is logged as an event by process 
402 using conventional database technology. Logged events are stored for a time in events 
data base 404. Synchronization of multiple parallel event reporting nodes may result in 
additional database transactions by event reporting node 1 16 as to records in events data base 

20 404. 

From time to time records from events data base 404 are provided to reconciling node 
118. Process 406, using conventional data base technology, accomplishes the comparison of 
records having one or more respective field values that are identical. In one variation, the 
tracking field is used exclusively. Table 502 in FIG. 5 identifies results of reconciliation for 

25 several combinations of reports being reconciled. If for a given tracking field value (or at a 
given time, date, content requesting node, and content providing node), reports A 332, B 342, C 
326, D 328, and possibly E 336 have been logged, then a group of messages accomplishing a 
normal request and payment for data transfer can be inferred to have been completed 
successfully. Allocation of earnings by process 408 follows the identification of such a 

30 reconciliation result. 

If on the other hand, one or more of the expected reports is not timely received for 
reconciliation having the given common field values, then it can be suspected that software on 
one or more nodes of network 100 may have been manipulated, compromising network 
integrity. Due to the large number of content requesting nodes and the lack of physical controls 
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that could protect software on such nodes from being manipulated, it is likely that at least some 
of the failures to receive all expected reports may be a consequence of content requesting node 
software manipulation. In cases 508 and 510, some or all requested data transfer might have 
been successful; however, allocation of earnings may not be justified when there remains a 
5 possibility that a user of the respective content requesting node may insist that the debit to his 
account be reversed. 

Allocation of earnings by process 408 is consummated by generating, according to 
conventional banking messaging and data base technology, requests for funds transfer by 
process 410 in banking node 1 14. 
10 As described in detail above, network 100 overcomes the problems of the prior art and 

provides a basis for accurate allocation of earnings to the owners of rights in digital works 
stored on systems of the present invention or transferred according to methods of the present 
invention. These and other benefits are provided with lesser system performance penalties than 
heretofore possible. 

15 Particular data transfers in various embodiments of the present invention proceed over 

one or more interfaces that are maintained to prevent unauthorized access to the system that 
sent the data. Access may be to read data from the sender, change data stored by the sender 
(e.g., overwriting the data, modifying the data, or revising references to the data), or execute 
programs on a processor of the sender. According to various aspects of the present invention, 

20 data transfer across such an interface is conditionally permitted according to a protocol. Such a 
transfer is herein called a protected transfer which includes any transfer that provides a barrier 
to unauthorized access by omitting information that would facilitate further access if such 
information were available in association with the transfer. When source identification is not 
apparent to a receiver or receiving process, the protected transfer is an anonymous transfer 

25 from the point of view of the receiver or receiving process. 

For example, permit 3 13 is transferred across an interface that includes a network link 
between nodes 112 and 1 10 illustrated by line 146 and a protocol. The transfer is conditional 
according to the protocol. The protocol includes prerequisite events such as, inter alia, 
receiving request 315 and validating payment by process 310. As discussed above, the 

30 network link (line 146) is enabled for transferring (e.g., sending permit 313) without 
prerequisite action by the receiver of the permit (e.g., node 110); the permit is sent as an 
anonymous transfer; and the transfer of the permit is conditioned upon receiving a request 315 
that includes information for facilitating sending the permit (e.g., a network address of the 
content requesting node 1 10). Each of these aspects of the transfer of the permit to content 
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requesting node 1 1 0 is an aspect of the interface between nodes 1 1 2 and 1 1 0 and constitutes a 
barrier to unauthorized access to the sender, node 1 12, by processes at the receiver, node 110. 
The protected transfer is anonymous because it is sent without including complete 
identification of the sender in a manner that is apparent to the receiver or receiving process. 
5 For example, the following information may not be apparent to content requesting node 110 
and/or process 314: the network node address of node 112, the network node address of the 
sender (e.g., a firewall system being part of node 1 12 or indirection of network node addresses 
used by node 1 12), identification of process 312, or identification of ports and links used in the 
transfer. 

10 A protocol includes any system for maintaining and changing state on one side of an 

interface in accordance with an ordered sequence of states and predefined criteria for state 
change. A process or circuit that supports a protocol monitors to detect events; compares 
events to criteria for state change from a current state to a next state of the sequence; and, in 
response to detecting prerequisite event(s), changes the maintained current state to the next 

15 state. The sequence may define multiple ways of entering or leaving a particular state, each 
way associated with respective criteria. 

A process (e.g., an application program, an operating system, or any of the processes 
described with reference to network 100 and system 2500) may effect transfer of data across an 
interface using a port on each side of the interface. The port may be integral with the process or 

20 a separate functional entity. A port is a process or mechanism that provides or accepts data 
across an interface (e.g., via a link, a bus, or a signal path) in accordance with a protocol by 
detecting events, keeping state, and changing state in response to detected events. 

Data may be made secure from unauthorized access by eliminating interfaces between 
subsystems that store the data and subsystems that may desire access to the data. Elimination 

25 may include preventing a link from being established, disconnecting a bus, or blocking a signal 
path. Where an interface which could be misused exists, the risk of unauthorized data transfer 
across the interface may reduced by adding a protocol to the interface (e.g., requiring transfers 
to occur through ports), restricting state transitions in a protocol used at the interface, and/or 
using protected transfers as discussed above. For example, detection of particular events (e.g., 

30 known security attack techniques) by ports at the interface may lead to denial of access, and a 
larger number of intricate events (e.g., being able to provide correct identification of node 
addresses, ports, subsystems, and processes related to the transfer or existing at the interface, 
identification of a receiver or sender, presentation of credentials of the receiver or sender and 
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processes at the receiver or sender), may be set as criteria for gaining entry to a state in which 
transfer is permitted. 

A system for data transfer according to various aspects of the present invention may 
include a public network. Use of a public network (e.g., the Internet) simplifies data 
5 communication among any number of subsystems. For example, system 2100 of FIG. 21 
includes multiple subsystem facility 2102, public network 2112, bank subsystem 2132, retail 
subsystem 2136, and consumer subsystem 2138. Banking subsystem 2136 and retail 
subsystem 2136 are coupled for data transfer by private network 2134. Multiple subsystem 
facility 2102 includes a private network 2110 coupled to each of packaging subsystem 2104, 
10 delivery subsystem 2106, and security managing subsystem 2108. Each subsystem may 

include one or more conventional computer systems (e.g., servers or workstations) having data 
stored therein. 

Each illustrated subsystem performs a subset of the functions of system 2100. 
Additional subsystems may be added in alternate implementations; and, suitable combinations 

15 of functions may be performed on fewer physical subsystems without departing from data 
transfers of the type discussed above. For example, alternate implementations of system 2100 
may include at each illustrated subsystem any number of subsystems of the same functional 
type operating in parallel (e.g., for redundancy) or at the same or different locations (e.g., for 
added capacity or for specialization). Alternate implementations may include different 

20 subsystems in a multiple subsystem facility 2102 and include zero or any number of such 
facilities. In still another alternate implementation, retail subsystem 2136 is also coupled to 
private network 2110 and may be part of an expanded multiple subsystem facility. 

System 2100 facilitates delivery of data products (e.g., digital works) to consumer 
subsystem 2138 while maintaining security of data stored on various other subsystems 

25 including delivery subsystem 2106 and security managing subsystem 2108. For example, 
consumer subsystem 2138 may order products via data transfer 2122 to retail subsystem 2136. 
Retail subsystem 2136 may communicate with banking subsystem 2132 to assure payment for 
ordered products. Security managing subsystem 2108 may convey a permit to consumer 
subsystem 2138 to regulate access to products by consumer subsystem 2138. And, products 

30 prepared for delivery by packaging subsystem 21 04 may be delivered by delivery subsystem 
2106 to consumer subsystem 2138 as permitted by the permit. 

Without interfering substantially with the commercial value of the operations of system 
2100 as discussed above, the data maintained by the various subsystems of system 2100 is 
made secure as discussed above by virtue of the combination of several aspects of system 
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organization and operation. For example, data on other subsystems is made secure from 
processes on consumer subsystem 2138 in several ways including: (1) transactions 2122 with 
retail subsystem 2136 do not convey information leading to the identification of multiple 
subsystem facility 2102, its subsystems, or banking subsystem 2132; (2) there is no interface 
5 between consumer subsystem 2138 and banking subsystem 2132; (3) there is no interface 
between consumer subsystem 2138 and packaging subsystem 2104; (4) the permit is delivered 
via a protected transfer 2124; (5) the product is delivered via a protected transfer 2126; and (6) 
the permit does not include information sufficient for unlimited use of the product. 
The functions discussed above with reference to system 2100 facilitate an 

10 implementation of computer network 100 as aparticular application of system 2100. Though it 
is not necessary for each subsystem of system 2100 to be a node as discussed above or have a 
unique network address, subsystems in such an implementation may correspond to nodes as 
follows. Packaging subsystem 2104 may include content acquisition node 102, content 
managing node 104, and provider preparation node 106 including the processes and data 

15 storage functions discussed above with reference to these nodes. Delivery subsystem 2106 
may include store 216, list 318, send process 322, and report process 334 as discussed above. 
Security managing subsystem 2108 may include authorizing node 112 and reconciling node 
118 including the processes and data storage functions discussed above with reference to these 
nodes. Banking subsystem 2132 may include banking node 114 including the processes and 

20 data storage functions discussed above with reference to that node. Retail subsystem 2136 may 
include file 306, form request process 304 and event reporting node 1 16 and its processes and 
data storage functions. Consumer subsystem 2138 may include content requesting node 110 
including the processes and data storage functions discussed above with reference to that node. 
System 2100 performs methods which may include some operations that parallel operations 

25 discussed above with reference to network 100. 

System 2100 performs a method including selling a permit (e.g., as in 2200 of FIG. 22), 
delivering a product (e.g., as in 2300 of FIG. 23), and detecting a breach of security (e.g., as in 
2400 of FIG. 24). Each method includes an expression of a protocol for cooperation across 
various interfaces of system 2100. A method for selling a permit begins with a consumer 

30 requesting (2202) a catalog or otherwise indicating interest in a product in any conventional 
manner via cooperation of consumer subsystem 2138, data transfer 2122, and retail subsystem 
2136. A catalog is provided (2204) and the sale of a permit to the customer is closed (2204) via 
cooperation of retail subsystem 2136, data transfer 2122, and consumer subsystem 2138 in any 
suitable conventional manner. Payment is verified to have been adequately assured in any 
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suitable manner (e.g., by debit, credit, voucher, or gift certificate) by cooperation of retail 
subsystem 2136, private network 2134, and banking subsystem 2132. If payment is not 
adequately assured (2208) the method is terminated without delivery of a permit. Otherwise, a 
permit is issued (2210) to the consumer via a protected transfer via cooperation of security 
5 managing subsystem 2108, protected data transfer 2124, and consumer subsystem 2138. In 
response to receipt of the permit, the consumer stores (2212) the permit in any suitable manner, 
storing being performed by consumer subsystem 2138. For example, the permit may be stored 
in a secure registry via consumer subsystem 2138. The permit may be transferred in encrypted 
form. The permit in either encrypted form or clear form may be encrypted before storage. 

10 A method for delivering a product begins with the consumer requesting (2302) a 

permitted product via cooperation of consumer subsystem 2138, data transfer 2122, and retail 
subsystem 2136. Delivery subsystem 2106 may become aware that delivery has been 
requested in any conventional manner (e.g., notice from retail subsystem 2136 to delivery 
subsystem 2106, polling by delivery subsystem 2106, or as a result of batch processing). The 

1 5 deliverer provides (2304) the requested product to the consumer via a protected transfer via 
cooperation of delivery subsystem 2106, protected transfer 2126, and consumer subsystem 
2138. Li response to receipt of the product, the consumer stores (2306) the product, storing 
being performed by consumer subsystem 2138. The product is preferably transferred in a 
secured form (e.g., scrambled, encrypted, or streamed). The product may be stored in a secure 

20 registry. At any time permitted thereafter, the consumer may use (2308) the product in a secure 
manner. Use being accomplished at least via consumer subsystem 2138. Use may entail 
further delivery (e.g., repeating operations discussed above with reference to 2304 and 2306). 
After use, the produce may again be stored (2306). Accounting for use may be accomplished 
in any suitable manner before, during, or after use. 

25 A method for detecting breach of security begins by receiving reports of the reception 

of data of various types. At least two types of reception reports are received. According to 
various aspects of the present invention, any combination of two or more of the following 
reports may be received for each commercial activity involving any consumer. Reports may be 
received directly from the subsystem that received the data; or, received after being passed 

30 through or accumulated in any subsystem. Preferably, reporting does not create the need for 
any interface not already part of the permit and product delivery methods discussed above. The 
following types of reports may be received: (a) reception of request for a permit (2204) as 
received by retail subsystem 2136; (b) reception of a permit (2212) as reported to retail 
consumer subsystem 2138; (c) reception of a request for a product to be delivered (2302) as 
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received by retail subsystem 2136; (d) reception of notice that delivery of a product has started 
(2304) as reported to retail subsystem 2136; or (e) reception of notice that delivery of a product 
has completed (2304) as reported to retail subsystem 2136. For each report received during a 
suitable period of time (2404), it is determined (2406) whether the report is part of a tuple (e.g., 
5 an association) of reports. This analysis of reports may be accomplished fully or in part in the 
retail subsystem so as to assure that consumer complaints regarding data transfers can be easily 
diagnosed; and/or may be accomplished fully or in part in the security managing subsystem 
2108 to assure that violations of permitted deliveries and uses can be easily investigated. If an 
unmatched report remains (2408) after analysis (2404), or if an incomplete tuple remains (2410) 
1 0 after analysis (2404), a breach of security may be noted or reported (24 1 2) in any conventional 
manner. 

As discussed above, the functions of various subsystems of system 2100 may be 
performed in combination. Functional groupings of functions are preferred for scaling the 
responsiveness (e.g., avoiding network and computational delays) and scaling the data storage 
1 5 capacities (e.g., physical locations of storage devices) of system 2100. Nevertheless, interfaces 
between processes that perform particular functions may be omitted if no protected transfer 
crosses the interface. 

A system architecture is a plan by which system functions are made the responsibility 
of particular processes for, inter alia, efficient performance of system functions and for 

20 efficient communication among processes. The system architecture is systematically applied 
as implementations of the system are developed and expanded. For example, system 
architecture 2500 of FIG. 25, includes packaging functions 2501, security managing functions 
2502, retail functions 2503, banking functions 2504, delivery functions 2505, and consumer 
functions 2506. Data transferred between packaging functions 2501 and security managing 

25 functions 2502 crosses interface 2515. Data transferred between packaging functions 2501 and 
delivery functions 2505 crosses interface 2516. Data transferred between security managing 
functions 2502 and retail functions 2503 crosses interface 2531 . Data transferred between 
security managing functions 2502 and consumer functions 2506 crosses interface 2530. Data 
transferred between security managing functions 2502 and delivery functions 2505 crosses 

30 interface 2529. Data transferred between retail functions 2503 and banking functions 2504 
crosses interface 2545. Data transferred between retail functions 2503 and consumer functions 
2506 crosses interface 2546. Data transferred between consumer functions 2506 and delivery 
functions 2505 crosses interface 2566. 
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Where no data transfers cross an interface between two groups of functions, the 
interface may be implemented by hosting the two groups on separate servers or hosting on an 
operating system that does not permit communication between processes to exist or go 
unnoticed 

5 Any conventional protocol may be used when implementing an interface with ports as 

discussed above. Ports are omitted from FIG. 25 for clarity but would suitably be employed to 
govern any data transfer paths or interfaces discussed above. The number of ports to be 
included in an implementation according to system architecture 2500 may be reduced from that 
implied by the functional groups illustrated in FIG. 25, for example, by hosting any convenient 

10 aggregation of functions on a common host where an interface between functions need not be 
erected. For instance, if functions of packaging subsystem 2104 and delivery subsystem 2106 
were to be hosted on one server, interface 2516 may be omitted, a common port supporting a 
network protocol for private network 2110 may be used for data transfers across interfaces 
2515 and 2529; nevertheless, a separate port is recommended for protected data transfer 2565 

15 (implementing 2126) across interface 2566. Security managing functions 2502 may be hosted 
with other functions, nevertheless, a separate port is recommended for protected data transfer 
2525 (implementing 2124) across interface 2530. 

Processes described with reference to FIG. 25 may be implemented in any conventional 
computer technology including multitasking environments wherein processes produce outputs 

20 whenever sufficient inputs are received. Interprocess communication may include remote 
procedure call, polling, interruption, or other process or thread scheduling techniques. Data 
maybe stored using any conventional technology including, for example, hierarchical or 
relational database, document object models, or markup languages (e.g., XML). 

Packaging functions 2501 include define products process 2509, establish rights 

25 process 2511, and issue products process 25 1 3 . Data related to these functions is stored in store 
2508 including content in clear form, product definitions, and permit terms. Store 2508 
includes data (also called content) for products. Data may be stored in unencrypted (clear) 
format. A product is data in any form. A product may include content from any conventional 
sources and combined in any conventional manner. Examples of products include a computer 

30 program executable file, a database, printed music with text, a novel with graphic art, a 
newspaper subscription, digitized audio of a song as performed, an animated cartoon with 
audio and video, a movie with commercial intermissions and subtitles, a stream of raw or 
analyzed data derived from telemetric instrumentation in real time, an interactive tutorial for 
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distance learning. Some of these products are delivered as a unit in total before use. Others are 
delivered in streaming format to be used while being delivered. 

Define products process 2509, with operator input, defines a product by identifying 
files of store 2508 that are desired to constitute a product; assigning a product identifier; and 
storing the foregoing information indexed by product identifier in store 2508 as product 
definitions (e.g., primary master copies). With operator input and In response to receipt of 
particular product identifiers 2510 from define products process 2509, establish rights process 
251 1 defines any conventional rights for use and/or disposition of the product(s) . Rights 
including pricing and distribution controls may be defined as rules in any suitable rights 
grammar, preferably an industry standard rights expression language. Rights for particular 
products may be stored as permit terms indexed by product identifier in store 2508. Rights and 
product definitions (e.g., including title, author, description) are conveyed 2512 by data 
transfer across interface 2515 to issue catalog information process 2519. 

Architecture 2500 supports the delivery of products to numerous sites having delivery 
functions from numerous sites having packaging functions. Operator input to issue products 
process 2513 may define a particular delivery site to which products (e.g., secondary master 
copies of products) are to be issued. Issue products process 2513 may encrypt or scramble 
content conveying the issued products in any suitable conventional manner before transferring 
corresponding data across interface 2516. The form chosen typically is such that can be 
decrypted by decrypt process 2558. Keys used for encryption may be unique to each delivery 
site or type of product or both. Keys may be issued by process 2521 and stored in store 25 1 8 in 
any conventional manner. After packaging, the formulation of a product as a series of files 
stored in clear content in store 2508 may bear no apparent resemblance to the issued package 
(e.g., delivered as a database having different file organization). 

Security managing functions include issue catalog information process 2519, issue key 
process 2521, issue permit process 2523, schedule deliveries process 2526, and assemble 
reports process 2528. Data related to these functions is stored in store 25 1 8, including product 
descriptions, product permits, keys, schedules, and delivery logs. Delivery logs include logs of 
the delivery of software (e.g., programs issued to consumer subsystems for maintaining 
security of deliveries), logs of the delivery of licenses, and logs of the delivery of products. 
Logs are indexed in any convenient manner for access by processes 2519-2528 and for 
ascertaining security breaches. 

Architecture 2500 supports the dissemination of product information (e.g., title, 
description, price, usage terms, product identifier) to numerous sites having retailing functions 
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from numerous sites having security managing functions. Issue catalog information process 
2519 disseminates data received (2512) from time to time from packaging functions. 
Information for keeping a retailer's catalog up to date is dispensed by data transfer 2520 to the 
retail site identified as specified by operator input or in schedules stored in store 2518. 
5 Information may be transferred across interface 253 1 in any suitable form including encrypted 
form particular to a retail site (e.g., when information is considered competition sensitive). 

In response to receipt of authorization to issue a permit (2532), issue permit process 
2523 requests (2522) and obtains (2524) one or more keys from issue key process 2521. One 
or more keys are used to encrypt usage terms, product identifiers, and other fields of a permit 

10 prior to transfer to a consumer. Additional and preferably different keys are used to encrypt 
product for transfers such as 2514 and 2565. Data (e.g., a permit) encrypted with a first key 
may be encrypted with a second key preferably different from the first key. 

In response to receipt of a request 2543 made by set up deliveries process 2542, 
schedule deliveries process 2526 determines a suitable date and time to initiate delivery of the 

1 5 requested product. Scheduling may give priority to predetermined types of requests, products, 
consumers, usage terms, and network load. Schedule deliveries process 2526 may maintain 
queues for each priority and arbitrate among queues to select a queue to draw from to provide a 
request 2527 to deliver product to delivery functions 2505. Request 2527 crosses interface 
2529 and may be subject to passing through ports at the interface for improved security. 

20 When a request 2527 has been made, schedule deliveries process 2526 reports status 

2544 to set up deliveries process 2542. In response to receipt of reports (e.g., start of delivery, 
end of delivery, interruption of delivery) from deliver products process 2563, schedule 
deliveries process 2526 may report the same (2544) to set up deliveries process 2542. 

Periodically, set up deliveries process 2542 may provide reports 2547 in raw or in tuple 

25 form to assemble reports process 2528. Assemble reports process 2528 may analyze these 
reports for any implied breach of usage rights and report results to an operator. Assemble 
reports process 2528 maintains delivery logs in store 2518 and responds to operator input for 
the presentation of summary or analysis based on queries of delivery logs using any 
conventional data base analytical and presentation techniques. In an alternate implementation, 

30 assemble reports process 2528 may direct banking functions to make royalty payments for 
delivery and use of the works processed as various products over a suitable period of time. 

Retail functions include maintain catalog process 2534, sell permit process 2536, 
assure payment process 2539, and set up deliveries process 2542. Data related to these 
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functions is stored in store 2518, including catalogs, subscriptions to products (e.g., 
newspapers) that become available periodically, and session logs. 

Maintain catalog process 2534 receives updates 2520 and maintains current catalog 
information in store 2533 (e.g., including numerous catalogs for different types of consumer 
5 requests). Catalog information is sufficient to close a sale for a permit according to any form 
usage rights that are priced in the catalog. If a user desires usage rights or products other than 
what appears as a line item in the catalog, the request may be logged for batch consideration by 
an operator of a packaging or security managing subsystem, referred to an operator for 
customer support (e.g., to persuade the consumer to buy what is offered or a substitute), or 
10 ignored. 

Sell permit process 2536 receives a request to purchase a permit from order permit 
process 2582 and, in response, requests (2537) and receives (2535) catalog information 
requisite for completing sales of the requested and possibly related permits. The sale may 
include return of a permit (2581) for credit or for replacement with any other permit (e.g., 

15 expanding or contracting usage rights for the same or different products). On providing the 
consumer with a purchase confirmation request, sell permit may receive purchase confirmation 
and proceed with collecting payment. 

Assure payment process 2539 receives from sell permit process 2536 authorization 
(2538) to prepare a financial transaction that resulted from sales activity (e.g., buy or refund). 

20 Assure payment process 2539 presents one or more financial transactions 2540 (e.g., debit, 
credit, transfer) to clear transactions process 2550 and receives confirmation 2541 that an 
account was successfully adjusted. In response to receiving such confirmation, assure payment 
process 2539 notifies (2532) issue permit process 2523 to issue a permit as discussed above. 
Without confirmation from clear transactions process 2550, no permit will issue because no 

25 request to issue a permit 2532 will be transferred across interface 2531. 

Set up deliveries process 2542 receives requests for deliveries of permits and products. 
In response to receipt of a request for operating software from register process 2572, set up 
deliveries process 2542 notifies schedule deliveries process 2526 to initiate the requested 
delivery. Operating software may be requested and delivered using the same request and 

30 delivery paths as discussed herein for a product. Specifically, delivery of software may include 
a protected transfer 2565 as discussed above. In response to receipt of a request 2581 from 
order product process 2578 to have a product delivered, set up deliveries process 2542 notifies 
schedule deliveries process 2526 to initiate the requested delivery. 
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Set up deliveries process 2542 receives various reports (2577, 2580, 2544) as described 
above with reference to method 2400. Set up deliveries process may perform any method (e.g., 
2400) to ascertain and report to security managing functions 2502 indications of proper and 
improper deliveries. Information concerning proper deliveries may be reported to an operator 
5 or a conventional retailing process for developing leads, developing consumer demand, or 
promoting products. 

Banking functions include clear transactions process 2550. Account balances and 
transaction logs are kept in data store 2551. Banking functions may be accomplished by any 
conventional network of financial clearing houses. Account information may be distributed 
1 0 among a variety of commercial banking institutions, each providing a portion of the banking 
functions as shown. 

Delivery functions include maintain inventory process 2555, read process 2556, 
decrypt process 2558, encrypt process 2561, and deliver products process 2563. Data related to 
these functions is stored in store 2554, including products in encrypted form, indexed by 

1 5 product identifier. Maintain inventory process receives products issued to it by packaging 
functions, namely issue products process 2513. Products may be stored in store 2554 in any 
suitable conventional manner for security, ease access and maintenance. 

In response to receiving a request 2527 for delivering a product, read process 2556 
accesses product inventory on store 2554 to obtain the product to support the requested 

20 delivery mode (e.g., download in total, stream at a specified data rate, or broadcast or multicast 
to multiple consumers). Read process then enqueues the product (or portions) 2557 for access 
by decrypt process 2558 so that encryption and security functions effected by issue products 
process 2513 may be removed. Read process provides keys supplied in the request 2527 to 
decrypt and encrypt processes 2558 and 2561. Clear content 2539 is provided by decrypt 

25 process 2558 to encrypt process 2561 . Encrypt process 2561 encrypts clear content 2539 to 
provide encrypted content 2562. Deliver products process 2563 receives encrypted content 
2562 and, via a protected transfer, provides it to manage product copies process 2583. On start 
and on completion of delivery, deliver products process 2563 may provide reports 2564 to 
schedule deliveries process 2526. Deliver products process may also report receipt of a request 

30 to deliver a product 2527. Deliver products process may include a port for any conventional 
communication protocol including wired and wireless protocols. 

Consumer functions include register process 2572, manage licenses process 2574, 
order product process 2578, manage product copies 2583, and order permit process 2582. Data 
related to these functions is stored in store 2570 including a consumer's key and a secure 
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registry. A consumer's key may be a simple symmetric key or may be a public key of a 
public/private dual key system issued by issue key process 2521 . The secure registry includes 
information necessary to order permits, order content, and use content that has been delivered 
to the consumer. 

5 A computer (e.g., a personal computer, personal digital assistant, wireless device, 

telephone, laptop, or workstation) after installation and configuration of software to perform 
the functions described herein may operate with system 2500 as a consumer substation. Such 
software may include a suitable operating system (e.g., to assure security functions are not 
breached); access software for connection and browsing a public network (e.g., a conventional 

1 0 web browser of the type used for browsing and shopping via the Internet); software to establish 
a secure container, a secure registry, and a secure manager to be used for all access to the 
registry and container; special purpose software for using the products delivered (e.g., a word 
processor for using text based products, a media player for using audio and video products, 
inline decryption/encryption software for using products in an encrypted form); a key stored in 

15 the registry or secure container used, for example, for making requests of other functions of 
system 2500; tamper resistance software to make difficult the unauthorized analysis and 
modification of the installed configuration; and, tamper evidencing software that detects and 
reports attempts at analysis or modification (e.g., substitution) of components of the installed 
configuration including the secure container, secure registry, permits, and products. Such 

20 software may cooperate with hardware (e.g., circuit assemblies, smart cards, or read only 
media) that form part of the installed configuration. Such software and hardware performs 
suitable conventional functions except as described herein in cooperation with consumer 
functions 2506. 

The following processes may be implemented to cooperate with a browser, simplifying 
25 shopping and using products by providing the user with a uniform interface that hides the 
details of the communication methods discussed above. 

Automatically on lapse of a timer or on user input, register process 2572 makes requests 
for adding to and updating the software configuration of a consumer subsystem. Register process 
2572 provides a request 2573 to set up deliveries process to initiate such delivery or update of 
30 software as discussed above. 

In response to user input, order permit process 2582 makes a request 2581 for purchasing 
a permit. The request may be the result of shopping or may initiate shopping by the consumer. 
Shopping includes presentation of catalog descriptions in response to any conventional queries 
specified by the user of the consumer substation. Such a request initiates the sale for issuance of a 
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permit as discussed above. By providing the permit via a protected transfer, a security attack by 
the user is likely to be ineffective because the user is not provided with information sufficient to 
search for additional information that may aid the security attack. 

Manage permits process 2574 receives a permit via a protected transfer 2525 and reports 
5 such receipt (2573) to set up deliveries process 2542. 

In response to user input, order product process 2578 requests (2576) and obtains (2575) 
usage rights and product identification from manage permits process 2574 representing results of 
a query on current permitted products that have not been delivered. A request for product delivery 
(2579) preferably includes a copy of the permit granting the right to receive the product. 
1 0 Forwarding the permit through retail functions 2503, then through security managing functions 
2502, to be acted upon by delivery functions 2505 may be accomplished using any conventional 
indirect addressing technology including indirection provided under Internet Protocols (e.g., 
HTTP) or conventional firewall design. 

Table 1 describes fields as used in the data structures illustrated in FIG. 26. Data 
1 5 structures of FIG. 26 may be represented in memory or in messages using any conventional 
technology. Each data structure implements associations (e.g., each combination being a tuple) 
among the indicia of functional values described in the Table. 

TABLE 1 



Field 


Description 


consumer transaction identifier 


An identifier assigned by the consumer 
functions. May be a combination of host 
identifier, date, and time. 


consumer node address 


A network address (e.g., a world wide port 
name, or Internet Protocol address) 


consumer host identifier 


An identifier designed to be unique to each 
consumer substation. May be based on serial 
numbers associated with products that make up 
the hardware and software configuration of the 
workstation and its peripherals used to form the 
consumer workstation. 


consumer public key 


A key used, for example, to encrypt delivery of 
a permit. 
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Field 


Description 


product identifier 


An identifier assigned by the packaging 
functions. Similar in function to an 
international standard book number (ISBN). 


delivery date and time 


A date and time when a delivery is expected to 
be made. Used for scheduling deliveries. 


product usage rights 


Usage rights in a conventional grammar. Dates 
and times may be specified in usage rights. The 
delivery date and time discussed above must 
fall within the usage rights. 


permit product key 


A key used, for example, to encrypt product 
permitted to be delivered under this permit. 


permit seal 


An authentication symbol (e.g., a character 
string of any suitable complexity) used to erect 
another barrier to attacking the security of the 
communication. May be a checksum based on 
the contents (hash) of the permit 


request3 consumer date time 


A time when the request3 was made. 


packaging decryption key 


This key is used by packaging functions to 
encrypt products; and by decrypt process 2558. 
May be unique to each delivery subsystem. 


delivery encryption key 


This key is used by encrypt process 2561 . May 
be unique for each permit, each product, each 
consumer transaction, or a combination of 
these. Multiple keys may be used in series on 
the product for each of these identifiers. 



The present invention has been described in the preferred embodiments. Several 
variations and modification shave also been described and suggested. Other embodiments, 
variations, and modifications known to those skilled in the art may be implemented without 
5 departing from the scope and spirit of the invention as recited in the claims below. 
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CLAIMS 

What is claimed is: 

1 1 . A method for reducing the risk of unauthorized access to a data product, the method 

2 comprising: 

3 a. conveying data in a first protected transfer to deliver a permit; and 

4 b. conveying data in a second protected transfer to deliver the data product in 

5 accordance with the permit. 

1 2. The method of claim 1 wherein conveying to deliver a permit comprises conveying 

2 from a source to a consumer subsystem without conveying indicia of identification of the 

3 source, conveying being in response to a first notice that payment for the permit has been 

4 assured by a first provided process, assuring being in response to receiving at the first 

5 provided process a request for the permit that originated from the consumer subsystem, the 

6 request for the permit being without indicia of the identification of the source. 

1 3 . The method of claim 2 wherein conveying to deliver the data product comprises 

2 conveying a portion of a data product from the source to the consumer subsystem without 

3 conveying indicia of identification of the source, conveying being in response to a second 

4 notice that a request for the data product has been received by a second provided process 

5 from the consumer subsystem. 



1 4. The method of claim 1 further comprising: 

2 receiving at least two reports during a time period; 

3 grouping reports into tuples of related reports; 

4 determining whether a particular report remains unmatched; 

5 determining whether a particular tuple remains incomplete; and 

6 providing notice of a breach of security in accordance with at least one of whether the 



7 particular report remains unmatched and whether the particular tuple remains incomplete. 

1 5. A method for reducing the risk of unauthorized access to a data product, the method 

2 comprising: 
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3 conveying a permit from a source to a consumer subsystem without conveying indicia 

i 

4 of identification of the source, conveying being in response to a first notice that payment for 

5 the permit has been assured by a first provided process, assuring being in response to 

6 receiving at the first provided process a request for the permit that originated from the 

7 consumer subsystem, the request for the permit being without indicia of the identification of 

8 the source; and 

9 conveying a portion of a data product from the source to the consumer subsystem 

10 without conveying indicia of identification of the source, conveying being in response to a 

1 1 second notice that a request for the data product has been received by a second provided 

12 process from the consumer subsystem. 

1 6. The method of claim 5 wherein the source comprises a multiple subsystem facility. 

1 7. The method of claim 6 wherein the indicia of identification of the source identifies the 

2 multiple subsystem facility. 

1 8. The method of claim 6 wherein the multiple subsystem facility comprises: 

2 a first subsystem for conveying the permit; 

3 a second subsystem for conveying the portion of the data product; and 

4 a private network coupling the first subsystem to the second subsystem. 

1 9. The method of claim 8 wherein the indicia of identification of the source identifies the 

2 first subsystem. 

1 10. The method of claim 8 wherein the indicia of identification of the source identifies the 

2 second subsystem. 

1 11. The method of claim 5 wherein the permit comprises items in a data structure that is 

2 encrypted. 

1 12. The method of claim 5 wherein the second request comprises at least a portion of the 

2 permit. 
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1 13. The method of claim 5 wherein the second notice comprises at least a portion of the 

2 permit. 

1 14. The method of claim 5 wherein the consumer subsystem comprises a consumer 

2 substation. 

1 15. The method of claim 5 wherein the consumer subsystem comprises a browser that 

2 initiates the request for the permit and the request for a data product. 

1 16. The method of claim 5 wherein the data product comprises at least one of a digital work, 

2 a file, an audio recording, a video recording, an executable program, a document, a 

3 multimedia program, and content. 

1 17. The method of claim 5 wherein conveying the portion of the data product comprises 

2 downloading the data product in entirety. 

1 18. The method of claim 5 wherein conveying the portion of the data product comprises 

2 streaming the data product. 

1 19. The method of claim 5 wherein conveying the permit comprises transferring data in a 

2 protected transfer. 

1 20. The method of claim 19 wherein the protected transfer comprises an anonymous transfer. 

1 21. The method of claim 5 wherein conveying the portion of the data product comprises 

2 transferring data in a protected transfer. 
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1 22. The method of claim 21 wherein the protected transfer comprises an anonymous transfer. 

1 23. The method of claim 5 wherein conveying the permit comprises: 

2 detecting a prerequisite event, the event being at least one of receiving the first notice 

3 and determining a network address of the consumer subsystem; and 

4 conveying data across an interface and from a port in accordance with a protocol that 

5 denies entry into a state for transferring data of the permit unless the event is detected. 

1 24. The method of claim 5 wherein conveying the portion of the data product comprises: 

2 detecting a prerequisite event, the event being at least one of receiving the second 

3 notice, receiving at least a portion of the permit, receiving a key for encrypting the portion of 

4 the data product, and determining a network address of the consumer subsystem; and 

5 conveying data across an interface and from a port in accordance with a protocol that 

6 denies entry into a state for transferring data of the product unless the event is detected. 

1 25. A system comprising: 

2 means for conveying data in a first protected transfer to deliver a permit; and 

3 means for conveying data in a second protected transfer to deliver a product. 

1 26. The system of claim 25 further comprising: 

2 means for receiving at least two reports during a time period; 

3 means for grouping reports into tuples of related reports; 

4 means for determining whether a particular report remains unmatched; 

5 means for determining whether a particular tuple remains incomplete; and 

6 means for providing notice of a breach of security in accordance with at least one of 



7 whether the particular report remains unmatched and whether the particular tuple remains 

8 incomplete. 

1 27. A system for communicating with a client having a client port, the system comprising: 

2 a. a first port that conducts a first transaction with the client port to establish a 

3 request for a permit and that conducts a second transaction with the client port to establish a 
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4 request for a data product, the request for a data product comprising at least a portion of a 

5 permit, the first port comprising a first plurality of processes; 

6 b. a second port that provides a permit to the client port in accordance with the 

7 request for the permit, the second port comprising a second plurality of processes; 

8 c. a third port that provides a data product to the client port in accordance with the 

9 request for the data product, the third port comprising a third plurality of processes; wherein 

10 d. processes of the first plurality and second plurality are coupled to convey at least a 

1 1 portion of the request for the permit and a portion of the request for the data product to the 

1 2 second plurality of processes; and 

13 e. processes of the second plurality and third plurality are coupled to convey at least 

14 the portion of the request for the data product to the third plurality of processes. 

1 28. The system of claim 27 wherein the second port is associated with a first network address 

2 and the third port is associated with a second network address. 

1 29. The system of claim 28 wherein the first port is associated with a third network address. 

1 30. The system of claim 29 wherein at least one of providing the permit and providing the 

2 data product comprises a data transfer according to a protocol that provides a barrier to 

3 access. 

1 31. The system of claim 30 wherein the barrier comprises omitting information that would 

2 facilitate access beyond the permit and the data product. 

1 32. The system of claim 3 1 wherein the omitted information includes an identifier associated 

2 with at least one of the second port and the third port. 

1 33. The system of claim 32 wherein the second port is enabled for providing the permit 

2 without action by the client subsequent to receiving the request for the permit. 
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1 34. The system of claim 33 wherein the third port is enabled for providing the data product 

2 without action by the client subsequent to receiving the request for the data product. 

1 35. The system of claim 34 wherein at least one of the permit and the request for the data 

2 product comprises a network address associated with the client port. 

1 36. The system of claim 35 wherein at least two of the first port, the second port, and the third 

2 port are hosted on one processor. 



1 37. A system for permitting authorized access by a client and for cooperating with a provided 

2 first interface that accesses a request for a permit, the request for a permit originating on the 

3 client, and that accesses a request for a data product, the request for a data product originating 

4 on the client and comprising at least a portion of a permit, the system comprising: 

5 a. a second interface that provides access of the permit across the second interface to 

6 the client, wherein: 

7 (1) the second interface comprises a first link between the system and the 

8 client for delivery of the permit; and 

9 (2) the first link is enabled in accordance with at least a portion of the request 

1 0 for the permit; and 

11 b. a third interface that provides access of a data product across the third interface to 

12 the client, wherein: 

13 (1) the third interface comprises a second link between the system and the 

14 client for delivery of the data product; and 

1 5 (2) the second link is enabled in accordance with at least a portion of the 

16 request for the data product, thereby conditionally permitting authorized access to the data 

17 product. 
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1 38. The system of claim 37 wherein the data product comprises at least one of a digital work, 

2 a file, an audio recording, a video recording, an executable program, a document, a 

3 multimedia program, and content. 

1 39. The system of claim 37 wherein access of a data product comprises at least one of 

2 receiving at least a portion of the data product over a network, executing at least a portion of 

3 the data product, reading at least a portion of the data product, and recalling at least a portion 

4 of the data product from a storage device. 
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